Method and system for account management

ABSTRACT

A method and system for managing accounts that control access to resources of different providers. The account management system allows providers to use a common logon procedure through an account management server. The account management system dynamically creates accounts when users request to access resources. To access to a resource, a user provides their credentials (e.g., user identifier and password) through a certain location (e.g., client computer) and identifies the resource (e.g., application). The account management system determines whether an account has already been created for those credentials. If not, the account management system authenticates the user, creates a new account for those credentials (i.e., registration), and associates the identified resource with the account.

TECHNICAL FIELD

[0001] The described technology relates generally to management ofaccounts; particularly, accounts for accessing computer resources fromvarious nodes.

BACKGROUND

[0002] Techniques for accessing computer resources (e.g., applicationprograms and computer data) require that the accessing user beauthorized to access the computer resource. The authorization istypically verified using a logon procedure in which a user suppliestheir credentials (e.g., user identifier and password) to the systemthat controls access to the computer resource. When the system receivesthe credentials, it determines whether the user is authorized to accessthe resource (e.g., by checking capabilities associated with the useridentifier). If so, then the system allows the user to access thecomputer resource. For example, a database program may require a user tosupply their user identifier and password before accessing (e.g.,reading and writing) the data in the database.

[0003] Such techniques for accessing computer resources are well adaptedto environments in which the computer resources (e.g., data in adatabase) are provided by a single source. For example, a news servicemay require a user to logon before accessing any news stories duringthat logon session. The news service may then bill the user on a monthlybasis for all the news stories accessed during the month. Each providerof computer resources typically develops their own logon procedures. Aproblem with such development is that each provider duplicates theefforts of other providers when developing their own logon procedures.Another problem with such development is that each provider may usedifferent types of logon procedures which tends to confuse users. Forexample, one provider may require a password to be at least 8 characterswhile another provider may require that passwords be 5 to 7 characters.Thus, a user who accesses the computer resources of both providers needsto remember different passwords. Even if different providers were to usethe same logon procedures, a problem would still exist in that a userwould receive separate bills from each provider. This problem may not besignificant if a user uses the computer resources of only a fewproviders, but it is significant when a user (e.g., an Internet user)accesses the computer resources of many different providers (e.g.,different news organizations and associations).

[0004] These problems could be solved if a procedure was provided by alogon organization that is not related to providers. For example, a userwould logon through a logon organization with a single set ofcredentials and then access the computer resources for differentproviders. Providers, however, typically find it undesirable to havetheir logon procedures provided by an unrelated source for severalreasons. First, providers prefer to have the displays associated withthe logon of their users to be integrated with the look and feel of theuser interface provided by the developer. Second, providers may preferto have provider accounts used when accessing the providers' servicesand resources. It would be desirable to have a technique that wouldcombine the advantages of the logon organization to avoid thesedifficulties, and yet enable providers to use established accounts andprovider-supplied logon elements.

BRIEF DESCRIPTION OF DRAWINGS

[0005]FIG. 1A illustrates a display page for entry of the useridentifier.

[0006]FIG. 1B illustrates a display page through which a user enterstheir temporary password and new password.

[0007]FIG. 1C illustrates a display page for identifying commonaccounts.

[0008]FIG. 2 is a block diagram illustrating the account managementsystem in one embodiment.

[0009]FIG. 3 is a block diagram illustrating the tables of the accountsdatabase in one embodiment.

[0010]FIG. 4 is a block diagram illustrating components of a clientcomputer in one embodiment.

[0011]FIG. 5 is a flow diagram illustrating the processing of the startapplication component of a client computer.

[0012]FIG. 6 is a flow diagram of the connect node component of theclient computer.

[0013]FIG. 7 is a flow diagram illustrating the processing of theregister user component of the client computer.

[0014]FIG. 8 is a flow diagram illustrating the processing of the logonuser component in one embodiment.

[0015]FIG. 9 is a flow diagram illustrating the processing of theprocess logon response component of the client computer.

[0016]FIG. 10 is a flow diagram of the processing of the register nodecomponent of the server computer.

[0017]FIG. 11 is a flow diagram of the processing of the connect nodecomponent of the server computer.

[0018]FIG. 12 is a flow diagram of the processing of the disconnect nodecomponent of the server computer.

[0019]FIG. 13 is a flow diagram of the processing of the register usercomponent of the server computer.

[0020]FIG. 14 is a flow diagram of the processing of the process logonrequest component of the server computer.

DETAILED DESCRIPTION

[0021] A method and system for managing accounts that control access toresources of different providers is provided. In one embodiment, theaccount management system allows providers to use a common logonprocedure through an account management server. The account managementsystem dynamically creates accounts when users request to accessresources. To access to a resource, a user provides their credentials(e.g., user identifier and password) through a certain location (e.g.,client computer) and identifies the resource (e.g., application). Theaccount management system determines whether an account has already beencreated for those credentials. If not, the account management systemauthenticates the user, creates a new account for those credentials(i.e., registration), and associates the identified resource with theaccount. If an account has already been created for those credentials,then the account management system associates the identified resourcewith that account. The account management system then notifies theprovider that the user is authorized to access the resource. In thisway, accounts are automatically created when a resource is accessed, andaccess to different resources using the same credentials automaticallyties the resources to the same account. To access a different resourceprovided by a different provider, the user again provides theircredentials and identifies the different resource. Since an account hasalready been created for those credentials, the account managementsystem simply associates the different resource with the account if notalready associated. Each provider can customize their logon proceduresas long as the provider adheres to the procedures defined by the accountmanagement system for acceptable credentials. By customizing their logonprocedures, a provider can use the account management system in such away that their users are not even aware of the account managementsystem. Because resources of two different providers are associated witha single account, the account management system can generate a singlereport (e.g., bills) for the user that reflects the user's access ofboth resources.

[0022] One aspect of the account management system provides a techniquefor identifying common accounts when a user provides differentcredentials for accessing different resources such as, for example, whenthe same user accesses one resource using one user identifier and thenaccesses another resource using another user identifier. In general, theaccount management system creates a separate account for each user, andthe user may have multiple unique sets of credentials. The accountmanagement system associates accounts with nodes or locations. It triesto identify common accounts when a user accesses a resource from onenode using credentials of an account associated with another node andthe node from which the user is accessing the resource already has anaccount associated with it. When the account management system createsan account, it associates that account with the node (e.g., computer)through which the user has requested to access the resource. When theaccount management system receives a request from the user at that nodeto access a resource of another account associated with another node, itdetermines whether the account associated with the node and the accountassociated with the other node should be considered the same account.For example, a household may have two computers. One family member mayhave accessed a resource from one computer using their own identifierand another family member may have accessed another resource (or thesame resource) from the other computer using their own identifier. Theaccount management system would create two accounts and associate theaccounts with the different computers. When one family member tries toaccess through the other computer a resource using their own identifier,the account management system detects that the account associated withthe computer and the account associated with the other computer arepossibly common accounts. The account management system may prompt theuser to indicate whether the different user identifiers should reallyrepresent the same account. If so, then the account management systemupdates its records to reflect that the two user identifiers representthe same accounts. In such a case, the users will access each resourceusing their own user identifiers. Since the accessing of both resourcesis tied to a single account, information relating to such accessing(e.g., billings, notifications, and preferences) may be combined. Theaccount management system similarly identifies common accounts when oneuser uses two different user identifiers. In an alternative embodiment,the account management system authorizes access to resources based onwhether that pair of credentials has already been associated with thatresource. If so, the account management system authorizes access to theresource. In this embodiment, the account management system may trackcombinations of credentials and resources. Thus, within one account,different sets of credentials (e.g., different user name and password)can be used to access different or even the same resource. To avoid userconfusion, the account management system may, however, require eachresource associated with an account to have only one authorized set ofcredentials, even though another resource of the account may beassociated with a different set of credentials. Thus, the credentials ofone family member cannot be used to access a resource of the commonaccount when that resource is associated with the credentials of theother family member.

[0023] Another aspect of the account management system allows users toaccess their accounts from different nodes. When a user requests toaccess a resource using a node and the user's account is not currentlyassociated with that node, then the account management system associatesthe account with that node. If the user specifies that access throughthe node is only on a temporary basis, for example, because the user isvisiting that node, then all information relating to the access to theresource is removed from the node after access to the resource iscomplete. The use of a node on a temporary basis is commonly called“roaming.”

[0024] FIGS. 1A-1C illustrate display pages provided by the accountmanagement system in one embodiment. FIG. 1A illustrates a display pagefor entry of the user identifier. This display page is typicallydisplayed by the application as soon as it is started. Display page 100includes a user identifier field 101 a password field 102, an existinguser button 103, and a new user button 104. If the existing user buttonis selected, the account management system attempts to log the user onto the application using the user identifier and password. If the newuser button is selected, then the account management system registersthe user (if not already registered), sends a temporary password to theuser, so that the user can log on as an existing user using thetemporary password. The temporary password may be sent through adifferent communications channel, such as by electronic mail message ortelephone. The use of a different communications channel known to beassociated with that user helps ensure that an imposter is not using theuser identifier. In one embodiment, user identifiers are the electronicmail addresses of the users. In this way, the account management systemcan send an electronic mail message to the address represented by theuser identifier. FIG. 1B illustrates a display page through which a usercan change their temporary password. Display page 110 includes atemporary password field 111, a new password field 112, a confirmpassword field 113, and continue button 114. After the user receives atemporary password, the user enters it into the temporary passwordfield, enters a new password, and selects the continue button. Assumingthat the temporary password entered by the user matches the temporarypassword generated by the account management system, then a new accountis confirmed for the user identifier and access to the identifiedapplication is authorized. This confirmation process helps with theinitial authentication of the user. FIG. 1C illustrates a display pagefor identifying common accounts. The account management system displaysthis display page when a user requests to access an application (i.e., aparticular type of resource) of an account that is not already assignedto the requesting node and at least one account is already assigned tothe requesting node. Display page 120 includes an account selection area121 with radio buttons and a continue button 122. The account selectionarea indicates that two accounts are currently assigned to therequesting node. The accounts may be identified by the names of theusers. The user indicates whether the account associated with theapplication to be accessed should be the same account as one of thedisplayed accounts. In one embodiment, the account management system mayrequire the user to enter a password associated with the selectedaccount to ensure that an imposter is not indicating that the accountsshould be common.

[0025]FIG. 2 is a block diagram illustrating the account managementsystem in one embodiment. Client computers 210 are connected to theserver computer 220 via the Internet 230. The computers may include acentral processing unit, memory, input devices (e.g., keyboard andpointing device), output devices (e.g., display devices), and storagedevices (e.g., disk drives). The memory and storage devices arecomputer-readable media that may contain instructions that implement theaccount management system. In addition, the data structures and messagestructures may be stored or transmitted via a data transmission medium,such as a signal on a communications link. Various communicationchannels other than the Internet may be used, such as a local areanetwork, a wide area network, or a point-to-point, dial-up connection.The server computer includes a server engine 221, a register nodecomponent 222, a connect node component 223, a disconnect node component224, a process register request component (new user) 225, a processlogon request component (existing user) 226, and an accounts database227. The server engine receives requests from the client computers andinvokes the appropriate component for processing the request. Theregister node component receives requests to register a client computerwith the account management system. Each node registers with the accountmanagement system before access to a resource from that node isauthorized. The connect node and disconnect node components controlconnecting client computer to the server computers. The process registerrequest component is invoked to process a registration request from anew user that is received from a client computer. Registration refers tothe process of assigning a new user identifier to a new account. Theprocess logon request component controls the logon of an existing user.A log on refers to the process of authenticating the user to access anapplication, account, or resource. The accounts database includesvarious tables for managing the accounts.

[0026]FIG. 3 is a block diagram illustrating the tables of the accountsdatabase in one embodiment. The accounts database includes a registerednode table 301, an account table 302, an application table 303, a usertable 304, and a registered connected node table 305. The registerednode table contains an entry for each registered node and indicates theaccounts associated with that node. For example, the first entry of theregistered node table indicates that the node with the node identifier“Home” is associated with account “A1” and account “A2.” Thisassociation means that all applications associated with both accountscan be accessed from that node. The account table contains an entry foreach account and indicates the applications associated with thataccount. For example, the first entry of the account table indicatesthat applications “O1,” “O2,” and “O3” are associated with account “A1.”This association means that access to these three applications are tiedto a common account. The account table may also indicate the credentialsassociated with each application of each account. By providingcredentials for each application, users of a common account can havetheir access to the applications limited to those who know thecredentials associated with that application. The application tablecontains an entry for each application that is available to be accessedby a user and may include a reference indicating where the applicationis stored. The user table contains an entry for each user (or moreprecisely each user identifier) and includes the password and theassociated account. For example, the first entry of the user tableindicates that user “U1” is associated with account “A1.” Theassociations in these tables means that user “U1” can access theapplications of account “A1” through nodes “Home” and “Work1.” Theconnected node table contains an lo entry for each node currentlyconnected to the server computer. For example, the first entry indicatesthat node “Home” is currently connected to the server computer.

[0027] Initially, the node table, account table, and user table areempty; and the application table contains an entry for each availableapplication (e.g., applications “O1,” “O2,” “O3,” and “O4”). When user“U1” requests to access application “O1,” the account management systemfirst adds an entry to the registered node table for node “Home” with noassociated account to effect registration of the node. The accountmanagement system then adds an entry to the account table for account“A1” that indicates the association with application “O1,” adds an entryto the user table for user “U1” that indicates the association withaccount “A1,” and updates the entry for the registered node table fornode “Home” to associate it with account “A1” to effect the registrationof the user. User “U1” may then request to access application “O2” fromnode “Home.” In response, the account management system notes that anentry for user “U1” is already in the user table, that the user isassociated with account “A1,” and that the entry in the registered nodetable for node “Home” is already associated with account “A1.” Theaccount management system then updates the entry in the account tablefor account “A1” to associate it with application “O2.” User “U1” thentries to access application “O3” from node “Work1.” Since the node“Work1” is not yet registered, the account management system adds anentry to the registered node table for node “Work1” without anyassociation to an account. The account management system determines thatthe user table contains an entry for user “U1” and that the user isassociated with account “A1.” The account management system then updatesthe entry in the registered node table for node “Work1” to associate itwith account “A1” and updates the entry in the account table for account“A1” to associate it with application “O3.”User “U1” can then accessapplications “O1,” “O2,” and “O3” from the nodes “Home” and “Work1.”User “U2” then requests to access application “O1” from node “Home.”Since user “U2” is new, the account management system adds an entry tothe account table for a new account “A2” associated with application“O1,” adds an entry to the user table for user “U2” associated withaccount “A2,” and updates the entry in the registered node table fornode “Home” to associate it with account “A2” to effect the registrationof the user. The person who used user identifier “U2” then requests toaccess application “O4” from node “Work2” using user identifier “U2′.”Since “U2” and “U2′” are not the same user identifiers, the accountmanagement system assumes the users are different. The accountmanagement system first adds an entry to the registered node table fornode “Work2” without being associated to any account. The accountmanagement system then adds an entry to the account table for account“A3” and associates it with application “O4,” adds an entry to the usertable for user “U2′” to associate it with account “A3,” and updates theentry in the registered node table for node “Work2” to associate it withaccount “A3.” If the user then tries to access application “O1” fromnode “Work2” using user identifier “U2,” the account management systemprompts the user to indicate whether account “A2” and account “A3” arecommon accounts. If the user responds affirmatively, then the accountmanagement system (not shown in the tables) updates the entry in theuser table for user “U2′” to associate it with account “A2” anddisassociate it from account “A3,” updates the entry in the accounttable for account “A2” to associate it with application “O4,” andupdates the entry in the register node table for node “Work2” toassociate it with account “A2” rather than account “A3.” The accountmanagement system then deletes the entry in the account table foraccount “A3.”

[0028]FIG. 4 is a block diagram illustrating components of a clientcomputer in one embodiment. The client computer includes an operatingsystem 410, application platform 420 and application storage area 430.The application platform includes the client-side portion of the accountmanagement system that includes a start application component 421, aconnect node component 422, a register user component 423, a logon usercomponent 424, a process logon response component 425, and a cache 426.The start application component is invoked when a user indicates tostart an application. The connect node component is invoked to connectthe client computer to the server computer and register the clientcomputer with the account management system if not already registered.The register user component is invoked to register a user with theaccount management system, and the logon user component is invoked tologon a registered user to an application. The process logon responsecomponent is invoked when the client computer receives a response fromthe server computer to a logon request. The cache may contain a copy ofportions of the account database relating to that client computer. Thecaching of this data allows the client computer to authorize access toapplications of accounts that are associated with the client computerwhen the server computer is unavailable.

[0029] FIGS. 5-14 are flow diagrams illustrating the processing of theaccount management system in one embodiment. FIGS. 5-9 are flow diagramsof components of a client computer. FIG. 5 is a flow diagramillustrating the processing of the start application component of aclient computer. This component connects the client computer to theserver computer and logs the user on to the application identified bythe user. This component is invoked by an application that the user haslaunched. In block 501, the component connects the client computer tothe server computer by invoking the connect node component. As part ofthe connection process, if the client computer is unregistered, it isregistered with the server computer. In decision block 501 a, if theconnection failed, then the component reports an error in block 508 andcompletes, else the component continues at block 502. In block 502, thecomponent inputs an indication of whether the user is a new user or anexisting user. If the user already exists, then the component inputs theuser identifier and password. In decision block 502 a, if this is thefirst time any application that uses the account management system isbeing launched at the client computer (then the client computer has noinformation about any user) or the user indicated that they were new,then the component continues at block 503, else the component continuesat block 504. In block 503, the component registers the new user byinvoking the register user component, which also logs the user onto theapplication. In block 504, the component logs the user on to theapplication by invoking the logon user component. In decision block 505,if the user was successfully logged on, then the component continues atblock 507, else the component reports an error to the user in block 506and loops to block 502 to begin attempting to log the user on to theapplication. In block 507, the component launches the applicationprogram and then completes.

[0030]FIG. 6 is a flow diagram of the connect node component of theclient computer. This component determines whether the computer isregistered with the account management system. If not, the componenteffects the registration of the client computer with the accountmanagement system. The component then connects the client computer tothe server computer. The registration process automatically connects theclient computer to the server computer. In block 601, the componentretrieves a node identifier that was stored if and when the clientcomputer was registered with the account management system. Theregistration of a node may be handled by a node management system thatis separate from the account management system. The node identifier maybe stored in a registry provided by the operating system. In block 602,the component validates the node identifier. In decision block 603, ifthe node identifier is valid, then the component continues at block 612,else the component continues at block 604. In block 604, the componentclears the current node identifier. In blocks 605-611, the componentregisters the client computer with the account management system or anode management system. In block 605, the component sends a registernode request to the server computer. In block 606, the componentreceives the response, including the node identifier, from the servercomputer. In block decision 607, if the response indicates success, thenthe component continues at block 608, else the component continues atblock 609. In block 608, the component stores the received nodeidentifier so that it is available in block 601 when the component isnext invoked and then returns an indication of success. In block 609,the component reports that the node could not be registered to the user.In decision block 610, the component determines whether the registrationshould be retrieved after a certain period. If so, the componentcontinues at block 611, else the component returns an indication offailure. In block 611, the component sets a timer (or uses some otherdelaying mechanism) and when the timer expires the component continuesat block 605 to retry the registration. In block 612, the componentsends a connection request to the server computer. The connectionrequest includes the node identifier and node address. In block 613, thecomponent waits for a response from the server. In decision block 614,if the response indicates a successful connection, then the componentreturns an indication of success, else the component returns anindication of failure.

[0031]FIG. 7 is a flow diagram illustrating the processing of theregister user component of the client computer. The register usercomponent coordinates the registration of a user that is new to theclient computer. If the client computer has already encountered the useridentifier, then the component prompts the user to see if the user isreally the same user. If the same, then the component proceeds to logthe user on to the application, else the component returns an error. Ifthe user identifier is new to the client computer, then componentregisters the user with the server computer and receives the accountidentifier in return and proceeds to log the user on to the application.In block 701, the component inputs the user identifier that was receivedthrough the display of FIG. 1A. The component may also input someadditional registration information such as the name of the user andbilling information. In decision block 702, if the user identifier is inthe cache of the client computer, then the user identifier is not newand the component continues at block 703, else the component continuesat block 707. In block 703, the component asks the user if the user isreally the same user who used this user identifier for anotherapplication. In decision block 704, if the user indicates that they arenot the same, then the component reports an error to the user in block706 because of duplicate user identifiers and then return an error, elsethe component continues at block 705. In block 705, the componentinvokes the logon user component to log the user on to the applicationand then returns the results of the logon. Blocks 707-712 are performedwhen the user identifier is indeed new to the client computer. In block707, the component sends a registration request to the server computerto register the user. The request includes the application identifier,user identifier and node identifier, but does not include an accountidentifier because none is known for this user. In block 708, thecomponent waits for a response to the registration request from theserver computer. In decision block 709, if the response indicates thatthe registration of the new user was successful, then the responseincludes the account identifier and the component continues at block710, else the component continues at block 711. In block 710, thecomponent caches the new account identifier, user identifier, andapplication identifier and continues at block 705 to log the user ontothe application. In decision block 711, if the user identifier isalready in use, then the component continues at block 703 to see if theuser is really the same, else the component continues at block 712 toreport some other error and then returns an indication of failure.

[0032]FIG. 8 is a flow diagram illustrating the processing of the logonuser component. The component coordinates the logon of a user to theapplication. This component is invoked after a new user has beensuccessfully registered or a user has indicated that they are anexisting user. If the user is not registered, then the component returnsan error. If the user is known to the client computer, then thecomponent sends the account identifier with the logon request to theserver computer. If the user is not known to the client computer, thecomponent sends the logon request without the account identifier. If theserver computer successfully log the user on to the application, theserver computer returns the account identifier. If the accountidentifier matches an account known to the client computer, then thecomponent caches the user's credentials, else the component combinesaccounts at the user's request. The user may choose to combine accountsor start using an account that is new to the node. If the logon is notsuccessful, then the component clears its cache of the user identifierpassword for the account. This component is invoked when a user requeststo access an application that has already been accessed from the clientcomputer or when a new application is being accessed using a useridentifier that has already been used at the client computer. In block801, the component inputs a user identifier and password. In decisionblock 802, if the server computer is available, then the componentcontinues at block 803, else the component continues at block 817. Inblocks 803-816, the component requests the server computer to log theuser onto the application. In block 803, the component sends a logonrequest to the server computer. The logon request includes the nodeidentifier, application identifier, user identifier, and password. Thislogon request does not include an account identifier that may have beencached by the client computer. In block 804, the component waits for theresponse from the server computer for that user identifier. For example,if a user identifier is being used that has not been used before at theclient computer, then the logon request does not include an accountidentifier. The response includes the account identifier associated withthe user identifier. In block 805, the component processes the logonresponse by invoking the process logon response component. In decisionblock 806, if the logon was successful, then the component continues atblock 807, else the component continues at block 813. In decision block807, if the account identifier returned in the response matches anaccount identifier known to the client computer, then the componentcontinues at block 808, else the component continues at block 809. Inblock 808, the component caches the user credentials (user identifierand password) in association with the account identifier and thenreturns an indication of a success. In block 809, the component askedthe user if the returned account is actually one of the accounts that isknown to the client computer by displaying the display page of FIG. 1C.In decision block 810, if the user selected a known account, then thecomponent continues at block 812, else the component continues at block811. In block 811, the component caches the new account identifier andcontinues at block 808. In block 812, the component collapses thereturned account and the user selected account into a single account andcontinues at block 802 to send a re-login request with the user selectedaccount to the server computer to collapse the two accounts. The servercomputer will detect that the user identifier is now being associatedwith the user selected account and is different from the returnedaccount and will collapse the two accounts into a common accountidentified by the user selected account. In decision block 813, if noaccount identifier is returned in the response, then the user has notyet been registered or the user's registration has been canceled andcomponent continues at block 815, else the component continues at block814. In decision block 814, if the password sent in the logon requestwas invalid, then the component continues at block 815, else thecomponent continues at block 816. In a block 815, the component clearsthe cache of the invalid user identifier and password for the accountand continues at block 820 to report an error. In block 816, thecomponent processes the error reported by the server computer and thenreturns a failure indication. In blocks 817-820, the component attemptsto locally authorize access (log on the user) to the identifiedapplication. In block 817, the component retrieves the cachedcredentials for the user identifier and application identifier. Indecision block 818, if the cached credentials were found, then thecomponent continues at block 819, else the component continues at block820 to report an error. In decision block 819, if the input passwordmatches the cached password of the credentials, then the componentreturns an indication of success, else the component continues at block820. In block 820, the component reports an error to the user andreturns an indication of failure.

[0033]FIG. 9 is a flow diagram illustrating the processing of theprocess logon response component of the client computer. This componentis invoked when a response to a logon request is received from theserver computer. In block 901, the component retrieves the response. Indecision block 902, the component determines whether the responseindicates that the logon was successful. A logon request can beunsuccessful if the account identifier sent in the request is invalid,the password sent in the request was invalid, or other server computererrors occurred. If the logon was successful, then the component returnsan indication of success, else the component returns an indication offailure.

[0034] FIGS. 10-14 are flow diagrams of components of the servercomputer. FIG. 10 is a flow diagram of the processing of the registernode component of the server computer. This component is invoked whenthe server computer receives a request from a client computer toregister a node. The component also connects the client computer to theserver computer. In block 1001, the component generates a unique nodeidentifier. In block 1002, the component adds the node identifier to theregistered node table to register the client computer. In block 1003,the component adds the node identifier and the node address (e.g., IPaddress and port address) to the connected node table to connect theclient computer to the server computer. In block 1004, the componentsends a response to the client computer that includes the nodeidentifier. The component then completes.

[0035]FIG. 11 is a flow diagram of the processing of the connect nodecomponent of the server computer. This component is invoked when theserver computer receives a request to connect a client computer. Theconnect request includes the node identifier of the client computer andthe node address. In block 1101, the component validates the nodeidentifier by comparing it to the entries in the registered node table.In decision block 1102, if the node identifier is in the registered nodetable, then the component continues at block 1103, else the componentcontinues at block 1104. In block 1103, the component adds an entry forthe node identifier and node address pair to the connected node tableand then returns an indication of success. In block 1104, the componentsends an error message to the client computer and closes the connectionand completes.

[0036]FIG. 12 is a flow diagram of the processing of the disconnect nodecomponent of the server computer. This component is invoked when theserver computer receives a connection close request from a clientcomputer. In block 1201, the component removes the entry for the nodeidentifier and node address pair from the connected node table. In block1202, the component closes the connection with the client computer, logsthe closing and then completes.

[0037]FIG. 13 is a flow diagram of the processing of the register usercomponent of the server computer. This component is invoked when theserver computer receives a request to register a new user from a clientcomputer. The request includes the user identifier and node identifier.If the user identifier is already registered, then the component sends aresponse that indicates the account number and that the user identifieris already in use. If the user identifiers is not registered, then thecomponent effects registration and sends a temporary password to theuser via e-mail. In decision block 1301, if the received node identifieris in the connected node identifier table, then the client computer isconnected and the component continues at block 1303, else the componentsends an error response in block 1302 and then completes. In block 1303,the component determines whether the user identifier is in the useridentifier table. In block 1304, if an entry for the received the useridentifier is in the user identifier table, then the user identifier isknown to the server computer and the component continues at block 1305,else the component continues at block 1309. In block 1305, the componentretrieves the account identifier for the user identifier from theaccount table. The component then sends a response to indicate that theuser identifier is already registered and then completes. In decisionblock 1309, if the account identifier is present in the receivedrequest, then the component continues at block 1310, else the componentcontinues at block 1311. In block 1310, the user identifier is new butthe account identifier was included in the registration request. As aresult, the component sends a response to the client computer indicatinga registration failure, which causes the client to ask the user to logonand then completes. In block 1311, the component creates a new accountidentifier in the account table. In block 1312, the component adds theapplication identifier, user identifier, and node identifier to theaccount table. In block 1313, the component generates a temporarypassword. In block 1314, the component sends an electronic mail messageinto the user indicating the temporary password. The component thencompletes.

[0038]FIG. 14 is a flow diagram of the processing of the process logonrequest component of the server computer. This component is invoked whenthe server computer receives a logon request from a client computer. Thelogon request includes the application identifier, user identifier,password, node identifier, and optionally account identifier. If theaccount identifier is included in the request and is valid but it doesnot match the account identifier that the server computer has associatedwith the user identifier, then the server computer collapses the twoaccounts into a single account that is identified by the receivedaccount identifier. The account identifier is not included when thatuser identifier has not been previously used at the client computer. Indecision block 1401, if the account identifier is present, then thecomponent continues at block 1402, else the component continues at block1408. In decision block 1402, if the account table contains an entry forthe received account identifier, then the account identifier is validand the component continues at block 1403, else the component continuesat block 1409 to report an error. In block 1403, if the user tablecontains an entry for the received user identifier, then the useridentifier is valid and the component continues at block 1404, else thecomponent continues at block 1407. In decision block 1404, if thepassword for the user identifier is valid, then the component continuesat block 1405, else the component continues at block 1409 to report anerror. In decision block 1405, if the account identifier associated withthe user identifier matches the received account identifier, then thecomponent continues at block 1412, else the component continues at block1406. In block 1406, the component collapses the two accounts into acommon account identified by the received account identifier andcontinues at block 1412. In block 1407, the component adds an entry tothe account table that maps the application identifier and useridentifier to the account identifier, and an entry to the user tablethat maps the user identifier to the temporary password. In block 1407a, the component sends the temporary password to the user via electronicmail and sends a response indicating failure to the client computer andthen completes. Blocks 1408-1414 are performed when no accountidentifier is included in the response. In decision block 1408, if thepassword is valid for the user identifier, then the component continuesat block 1410, else the component continues at block 1409. In block1409, the component sends an error response to the server computer andthen completes. In block 1410, the component retrieves from the usertable the account identifier associated with the user identifier. Indecision block 1411, if the node identifier in the request is associatedwith the retrieved account identifier, then the component continues atblock 1414, else the component continues at block 1412. In block 1412,the component adds an entry to the account table that maps of theaccount identifier to the node identifier. In block 1413, the componentadds an entry to the node table that maps the node identifier to theaccount identifier and then continues at block 1413. In block 1414, thecomponent adds the application identifier to the entry for account inthe account table and then sends a response to the client computer thatincludes the account identifier and then completes.

[0039] From the above description, it will be appreciated that althoughspecific embodiments of the technology have been described for purposesof illustration, various modifications may be made without deviatingfrom the spirit and scope of the invention. In one embodiment,credentials other than user identifier and password pairs can be used.For example, each user may encrypt certain information with theirprivate key of a public and private key pair. The server computer canuse the public key to decrypt the information to ensure that it wasencrypted with the correct private key. Also, the authentication can beperformed by a separate authentication server with the results beingsent back to the server computer or directly to the client computers. Inanother embodiment, each account can be identified by the useridentifiers that are assigned to that account. Thus, an account may beconsidered a group of one or more user identifiers. Also, the resourcesneed not be limited to computer resources. For example, the resourcesmay include people, groups or communities, physical goods,communications service (e.g., phone, video), and so on. Accordingly, theclaims are not limited except by the appended claims.

1. A computer-based method for identifying common accounts, the methodcomprising: assigning a first user identifier to a first account, thefirst account being associated with a first node; assigning a seconduser identifier to a second account, the second account being associatedwith a second node; receiving a request from the second node thatincludes the first user identifier, when the first account is notalready associated to the second node, determining whether the first andsecond accounts represent the same account; and when it is determinedthat the first and second accounts represent the same account, combiningthe first and second accounts into a single account.
 2. The method ofclaim 1 wherein the determining includes requesting a user to indicatewhether the first and second accounts represent the same account.
 3. Themethod of claim 2 including identifying the second account to the userby specifying a user name associated with the second account.
 4. Themethod of claim 2 wherein when the user indicates that the first andsecond accounts represent the same account, requesting that the userprovide credentials associated with the second account.
 5. The method ofclaim 1 wherein each account has a user and the user of the firstaccount is the same as the user of the second account.
 6. The method ofclaim 1 wherein each account has a user and the user of the firstaccount is not the same as the user of the second account.
 7. A methodof claim 1 wherein the combining includes deleting one of the accountsand assigning the user identifier assigned to the deleted account to theremaining account.
 8. The method of claim 7 including associating withthe remaining account a resource that was associated with the deletedaccount.
 9. The method of claim 1 including: when it is determined thatthe first and second accounts do not represent the same account,associating the first account with the second node.
 10. A computer-basedmethod of generating a common account, one account being associated witha node, the method comprising: receiving at the node informationrelating to an account; and when the account to which the information isrelated is not currently associated with the node, determining whetherthe account associated with the node and the node not currentlyassociated with the node should be common accounts; and when it isdetermined that the accounts should be common accounts, directing thecombining the accounts into a single account.
 11. The method of claim 10wherein the determining includes requesting a user to indicate whetherthe accounts are common accounts.
 12. The method of claim 11 wherein thedetermining includes identifying the account associated with the node tothe user by specifying a user name associated with that account.
 13. Themethod of claim 10 wherein each account is associated with one or moreuser identifiers.
 14. The method of claim 13 wherein the informationrelating to the account is a user identifier associated with theaccount.
 15. The method of claim 10 including determining that theaccount to which the information is related is not currently associatedwith the node by receiving an indication of that account from anothercomputer.
 16. A method in a computer system for identifying commonaccounts, the method comprising: receiving a user identifier from auser; sending a log on request to a server computer, the requestincluding the received user identifier, but not including an accountidentifier; receiving a log on response from the server, the responseincluding an account identifier associated with the received useridentifier; and when the received account identifier does not match anaccount identifier previously stored at the node, prompting the user toindicate whether the account identified by the received accountidentifier should be the same account as an account identified by anaccount identifier previously stored at the node.
 17. The method ofclaim 16 including when the user indicates that the accounts should becommon accounts, sending a log on request to the server computer, therequest including the received user identifier and an account identifierpreviously stored at the node.
 18. The method of claim 16 wherein theprompting occurs only if at least one account identifier was previouslystored at the node.
 19. A method in a computer system for authorizingaccess to applications, each application having an applicationidentifier, the method comprising: receiving a plurality of useridentifier and application identifier pairs; for each pair received,storing the user identifier in association with the applicationidentifier; receiving a request to access an application, the requestincluding a user identifier and application identifier pair, theapplication identifier identifying the application to be accessed; andwhen the user identifier and application identifier pair of the requestmatch a stored user identifier and application identifier pair,indicating that access to the application is authorized.
 20. The methodof claim 19 wherein the requested access is execution of theapplication.
 21. The method of claim 19 wherein the plurality of useridentifier and application identifier pairs are received in requests toaccess the application identified by the application identifier of thepair.
 22. The method of claim 19 including when the user identifier andapplication identifier pair of the request does not match a stored useridentifier and application identifier pair, indicating that access tothe application is not authorized.
 23. The method of claim 19 whereinaccess is authorized for applications developed by different applicationdevelopers.
 24. The method of claim 19 wherein the request is receivedand the authorization is indicated before starting execution of therequested application.
 25. The method of claim 19 wherein receivedrequests are sent by a plurality of client computers.
 26. The method ofclaim 19 wherein each application identifier and user identifier pairincludes a password and indicating that access to the application isauthorized only when the request includes a password that matches thepassword for the application identifier and user identifier pair of theplurality of application identifier and user identifier pairs.
 27. Amethod in a computer system for authorizing access to differentapplications, each application having an application identifier, themethod comprising: receiving a plurality of user identifier andapplication identifier pairs; and for each pair received, sending thereceived user identifier and application identifier pair to anauthorization system; receiving from the authorization system anindication whether access to the application identified by theapplication identifier is authorized.
 28. The method of claim 27 whereinthe authorization system maintains user identifier and applicationidentifier pairs that indicate the user identified by the useridentifier is authorized to access the application identified by theapplication identifier.
 29. The method of claim 27 wherein the receivingincludes receiving a password that is sent to the authorization systemwherein authorization is indicated only when the sent password matches apassword stored at the authorization system for the sent user identifierand application identifier pair.
 30. A method in a computer system forauthorizing access to a resource, each resource having a resourceidentifier, the method comprising: providing a plurality of useridentifier and resource identifier pairs, each user identifier andresource identifier pair indicating that the identified user isauthorized to access the identified resource; receiving a request toaccess a resource, the request including a user identifier and resourceidentifier pair, the resource identifier identifying the resource to beaccessed; and when the user identifier and resource identifier pair ofthe received request match a provided user identifier and resourceidentifier pair, indicating that access to the resource is authorized.31. The method of claim 30 wherein the resource is computer data. 32.The method of claim 30 wherein the resource is a communications channel.33. The method of claim 30 wherein the indicating that access to theresource is authorized occurs after performing authentication for theidentified user.
 34. The method of claim 33 wherein the authenticationincludes comparing a received password with a password associated withthe matched user identifier and resource identifier pair.
 35. A methodin a computer system for managing accounts, the method comprising:assigning an account to a node; receiving from the node a request toaccess a computer resource that is associated with an account that isnot assigned to the node; and in response to receiving the request,assigning the account associated with the computer resource to the nodeso that the computer resource can be accessed from the node.
 36. Themethod of claim 35 wherein the computer resource is an application. 37.The method of claim 35 including after access to the computer resourceis complete, un-assigning the account associated with the computerresource from the node.
 38. The method of claim 35 wherein the accountsassociated with the node represent accounts of different users.
 39. Themethod of claim 35 wherein the nodes are computers.
 40. The method ofclaim 35 wherein the computer resource is computer data.
 41. The methodof claim 35 wherein the computer resource is a user.
 42. The method ofclaim 35 wherein the computer resource is a communications channel. 43.A method in a computer system accessing a computer resource, the methodcomprising: assigning a different account to each of a plurality ofnodes; receiving from a node a notification that a user has requested toaccess a computer resource that is associated with an account that isassigned to another node; and in response to receiving the notification,temporarily assigning the account associated with the computer resourceto the node so that the user can access the computer resource from thenode.
 44. The method of claim 43 wherein after access to the computerresource is complete, all information relating to the temporarilyassigned account is removed from the node.
 45. The method of claim 43wherein after access to the computer resource is complete, un-assigningthe account from the node.
 46. A method in a computer system fortracking use of applications, the method comprising: receiving from aclient computer a request to access an application, the requestsincluding an application identifier and user identifier; determiningwhether the user identifier is associated with an account; when the useridentifier is associated with an account, sending to an authorizationcomputer a request to authorize access to the application, the requestincluding the user identifier; and upon receiving a response indicatingthat access is authorized, sending to the client computer a responseindicating that access is authorized.
 47. The method of claim 46 whereinthe request received from the client computer includes a password thatis sent to the authorization system.
 48. The method of claim 46including sending the application identifier to the authorizationsystem.
 49. A method in a computer system for managing account, themethod comprising: receiving a plurality of user identifiers;associating the user identifiers with a single account; receivingattributes when a user is logged on with one of the user identifiersassociated with the single account; and providing those receivedattributes when a user is logged on with another of the user identifiersassociated with the single account.
 50. The method of claim 49 whereinthe attributes includes preferences relating to access to anapplication.
 51. The method of claim 51 whereby the attributes areassociated with the single account rather than an single useridentifier.
 52. A computer-readable medium containing instructions forcausing a computer system to generate common account, one account beingassociated with a node, by a method comprising: receiving at the nodeinformation relating to an account; and when the account to which theinformation is related is not currently associated with the node,determining whether the account associated with the node and the nodenot currently associated with the node should be common accounts; andwhen it is determined that the accounts should be common accounts,directing the combining the accounts into a single account.
 53. Thecomputer-readable medium of claim 52 wherein the determining includesrequesting a user to indicate whether the accounts are common accounts.54. The computer-readable medium of claim 53 wherein the determiningincludes identifying the account associated with the node to the user byspecifying a user name associated with that account.
 55. Thecomputer-readable medium of claim 52 wherein each account is associatedwith one or more user identifiers.
 56. The computer-readable medium ofclaim 55 wherein the information relating to the account is a useridentifier associated with the account.
 57. The computer-readable mediumof claim 52 including determining that the account to which theinformation is related is not currently associated with the node byreceiving an indication of that account from another computer.
 58. Acomputer system for generating a common account, one account beingassociated with a node, comprising: means for receiving at the nodeinformation relating to an account; and means for, when the account towhich the information is related is not currently associated with thenode, determining whether the account associated with the node and thenode not currently associated with the node should be common accounts;and when it is determined that the accounts should be common accounts,directing the combining the accounts into a single account.
 59. Thecomputer system of claim 58 wherein the means for determining includesrequesting a user to indicate whether the accounts are common accounts.60. The computer system of claim 59 wherein the means for determiningincludes means for identifying the account associated with the node tothe user by specifying a user name associated with that account.
 61. Thecomputer system of claim 58 wherein each account is associated with oneor more user identifiers.
 62. The computer system medium of claim 61wherein the information relating to the account is a user identifierassociated with the account.
 63. The computer system medium of claim 58including means for determining that the account to which theinformation is related is not currently associated with the node byreceiving an indication of that account from another computer.
 64. Acomputer-readable medium containing instructions for controlling acomputer system to authorize access to different applications, eachapplication having an application identifier, by a method comprising:receiving a plurality of user identifier and application identifierpairs; and for each pair received, sending the received user identifierand application identifier pair to an authorization system; receivingfrom the authorization system an indication whether access to theapplication identified by the application identifier is authorized. 65.The computer-readable medium of claim 64 wherein the authorizationsystem maintains user identifier and application identifier pairs thatindicate the user identified by the user identifier is authorized toaccess the application identified by the application identifier.
 66. Thecomputer-readable medium of claim 64 wherein the receiving includesreceiving a password that is sent to the authorization system whereinauthorization is indicated only when the sent password matches apassword stored at the authorization system for the sent user identifierand application identifier pair.
 67. A computer-readable medium forcontrolling a computer system to authorize access to a resource, eachresource having a resource identifier, by a method comprising: providinga plurality of user identifier and resource identifier pairs, each useridentifier and resource identifier pair indicating that the identifieduser is authorized to access the identified resource; receiving arequest to access a resource, the request including a user identifierand resource identifier pair, the resource identifier identifying theresource to be accessed; and when the user identifier and resourceidentifier pair of the received request match a provided user identifierand resource identifier pair, indicating that access to the resource isauthorized.
 68. The computer-readable medium of claim 67 wherein theresource is computer data.
 69. The computer-readable medium of claim 67wherein the resource is a communications channel.
 70. Thecomputer-readable medium of claim 67 wherein the indicating that accessto the resource is authorized occurs after performing authentication forthe identified user.
 71. The computer-readable medium of claim 67wherein the authentication includes comparing a received password with apassword associated with the matched user identifier and resourceidentifier pair.
 72. A method in a client computer for coordinatingregistration of a user with a server computer, comprising: receiving auser identifier and an indication that the user is a new user; when theclient computer has previously cached that user identifier, promptingthe user to indicate whether the user is the same as the user associatedwith the previously cached user identifier; when the user indicates thatthe user is not the same, allowing the user to enter a new useridentifier; and when the user indicates that the user is the same user,coordinating log on of the user; and when the client computer has notpreviously cached that user identifier, registering the user; when theregistration is successful, caching the user identifier and coordinatinglog on of the user.
 73. A method in a client computer for log on of auser, comprising: receiving a user identifier and password; sending alog on request to a server computer, the request including an accountidentifier when the client computer has an account identifier associatedwith the received user identifier; when a response indicating that thelog on was successful is received, the response including an accountidentifier, when the account identifier does not match an accountidentifier previously cached at the client computer, prompting the userwhether the received account identifier and a previously cached accountidentifier represent the same account; and when the user indicates thatthe accounts represent the same account, combining the accounts.